home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20041116-20060924 / 000312_rock_spambust_violin@yahoo.com_Tue Apr 25 12:14:03 2006.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Path: newsmaster.cc.columbia.edu!newsfeed.nyu.edu!news.maxwell.syr.edu!newsfeed.media.kyoto-u.ac.jp!border2.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!i40g2000cwc.googlegroups.com!not-for-mail
  2. From: "tomviolin" <rock_spambust_violin@yahoo.com>
  3. Newsgroups: comp.protocols.kermit.misc
  4. Subject: Re: speed of script execution
  5. Date: 20 Apr 2006 10:29:35 -0700
  6. Organization: http://groups.google.com
  7. Lines: 57
  8. Message-ID: <1145554175.676504.188370@i40g2000cwc.googlegroups.com>
  9. References: <1145524573.729587.320320@z34g2000cwc.googlegroups.com>
  10.    <slrne4f65k.djh.fdc@sesame.cc.columbia.edu>
  11. NNTP-Posting-Host: 67.53.150.18
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset="iso-8859-1"
  14. X-Trace: posting.google.com 1145554180 10328 127.0.0.1 (20 Apr 2006 17:29:40 GMT)
  15. X-Complaints-To: groups-abuse@google.com
  16. NNTP-Posting-Date: Thu, 20 Apr 2006 17:29:40 +0000 (UTC)
  17. User-Agent: G2/0.2
  18. X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2,gzip(gfe),gzip(gfe)
  19. Complaints-To: groups-abuse@google.com
  20. Injection-Info: i40g2000cwc.googlegroups.com; posting-host=67.53.150.18;
  21.    posting-account=ornCOQwAAAAyCG4a7NOAj_SMr54FiqNu
  22. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15567
  23.  
  24. Frank da Cruz wrote:
  25. > On 2006-04-20, tomviolin <rock_spambust_violin@yahoo.com> wrote:
  26. > : Can anyone tell me why there is such a huge time discrepency between
  27. > : the execution of the following scripts.  The only difference is the
  28. > : curly braces.
  29. > As in C, the braces mark a block, entry to and exit from which carries some
  30. > setup and takedown cost.  When you have only one or two statements in the
  31. > block, that cost is a lot higher, proportionally, than if you have a lot of
  32. > statements in it.
  33. >
  34. > Block structure is a convenience and an aid to writing readable source code,
  35. > but it's not a necessity.  Every block structure can be decomposed into
  36. > something more rudimentary and lest costly in execution, using GOTOs or
  37. > whatever.  In fact, that's what happens internally anyway.  The only
  38. > difference is that with true blocks, various buffers and variables and other
  39. > context have to be stacked.
  40. >
  41.  
  42. Frank,
  43.  
  44. I have had an idea.  I am somewhat familiar with how Kermit breaks down
  45. structured code into GOTOs and the like (the code shows up when you
  46. have SET MACRO ECHO ON for example).
  47.  
  48. What if there was a way to do that decomposition in a function and then
  49. save the results to a new command file?  For example, part of my
  50. "larger system" does this:
  51.  
  52. -- begin kermit script --
  53. take \m(connect_id).ksc    ; always contains gd_connect
  54.                            ; and gd_disconnect macro definitions
  55. take \m(device_id).ksc      ; always contains a gd_acquire macro
  56. definition
  57. fopen /write \%f "getdata.ksc" ; to be executed later
  58. fwrite /line \%f "\m(gd_connect)"
  59. fwrite /line \%f "\m(gd_acquire)"
  60. fwrite /line \%f "\m(gd_disconnect)"
  61. fclose \%f
  62.  
  63. This basically turns a set of macros into inline code to be executed
  64. later.  This works great for very simple macro definitions that have no
  65. blocks in them.  As soon as blocks are introduced, wham, the execution
  66. time goes way up.
  67.  
  68. What I'm proposing is some function \fdecompose() that could perhaps be
  69. called like this:
  70.  
  71.    \fdecompose(\m(gd_connect))
  72.  
  73. that would take the "inlining" process to the next level, and produce
  74. the lower-level code with all the "goto .._blah" stuff, sort of like
  75. compiling to p-code in a way.
  76.  
  77. Or, is there a way to do this already?
  78.  
  79. -Tom
  80.